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I. 


INTRODUCTION 


This  thesis  identifies  challenges  in  the  use  of 
commercial-off-the-shelf  (COTS)  components,  a  type  of  non- 
developmental  items  (NDI),  in  mission-critical  but 
unclassified  systems.  The  U.S.  Department  of  Defense  (DoD) 
increasingly  turns  to  acquiring  COTS  components  in  order  to 
reduce  both  the  cost  and  time  to  acquire  a  system,  and  to 
standardize  support  for  deployed  systems. 

On  June  29,  1994,  then  Secretary  of  Defense  William 

Perry  issued  a  memorandum  prohibiting  the  use  of  legacy 

military  defense  standards  without  a  waiver  and  encouraged 
the  use  of  industry  standards.  Weapon  systems  were  required 
to  use  "performance  specifications"  that  described  the 
desired  features  of  the  weapon  system  instead  of  citing 
military  standards  [1]  .  This  memo  removed  the  requirement 
of  military  standards  and  specifications  and  has  lead  to 
DoD's  present-day  reliance  on  COTS  components. 

The  capabilities  provided  by  COTS  components  do  not 
always  match  up  with  the  requirements  of  DoD.  Usually, 

provision  of  built-in  security  features  for  such  mass- 
marketed  components  is  not  the  highest  priority  of  the 
developer.  Instead  the  developer's  focus  is  on  time-to- 
market  concerns  and  the  primary  functionality  of  the  system 
[2] .  The  reliability  of  such  components  and  the  security  of 
such  systems  are  assigned  a  low  priority  relative  to  the 

functionality  of  the  system. 

The  typical  development  cycle  for  software  and 

electronic  components  is  now  less  than  one  year,  making  it 

difficult  for  DoD  entities  to  perform  extensive  independent 
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verification  and  validation  (IV&V),  as  well  as  Information 
Assurance  (lA)  certification  and  accreditation  (C&A) ,  on  the 
systems  containing  COTS  components. 

COTS  components  tend  to  have  a  short  life  cycle, 
contributing  to  the  challenge  for  the  DoD  in  maintaining 
legacy  systems  due  to  the  unavailability  of  components. 
"Component  churn, "  that  is  the  movement  of  components  into 
or  out  of  service,  makes  IV&V  and  lA  C&A  even  more 
challenging . 

A  trustworthy  system  is  one  that  provides  the 
appropriate  levels  of  correctness  and  robustness  in 
accomplishing  its  mission  [3]  .  Trust  in  this  context  is 
especially  important  in  critical  yet  unclassified  systems 
which  affect  lives  and  national  assets,  yet  the  systems  have 
not  been  vetted  to  the  same  extent  as  systems  that  process 
classified  data. 

The  purpose  of  this  thesis  is  to  explore  the  current 
landscape  of  DoD  lA  as  it  pertains  to  COTS  components,  show 
how  Josang's  trust  model  can  be  used  to  calculate  trust 
based  on  opinions  provided  by  multiple  government  and  non¬ 
government  services,  and  explore  the  need  for  cross-domain 
sharing  of  information  to  support  populating,  maintaining, 
and  using  the  trust  models. 

A.  MOTIVATIONS  FOR  THIS  THESIS 

Consider  the  reverse  engineering  efforts  undertaken  by 
large  communities  of  people  to  exploit  commercially 
available  hardware  such  as  video  game  consoles,  cell  phones, 
and  Global  Positioning  System  (GPS)  receivers,  in  order  to 
remove  installed  security  features  and  add  functionality  not 
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included  in  the  original  systems.  Many  of  these  groups 
receive  little  or  no  monetary  compensation  for  their  efforts 
and  are  only  motivated  by  the  notoriety  they  receive  from 
their  exploits.  Such  groups  with  little  to  no  sponsorship 
have  successfully  thwarted  security  systems  specifically 
designed  to  prevent  such  actions. 


Figure  1.  Photograph  of  Xbox  internals. 

For  example,  in  November  of  2001,  Microsoft  released 

the  Xbox  video  game  console  based  on  common  personal 

computer  (PC)  hardware.  The  Xbox  is  essentially  a  PC  with 

an  Intel  Mobile  Celeron  processor,  hard  drive,  nVidia 

GeForce  video  card,  random  access  memory  (RAM) ,  Ethernet 

port,  and  Universal  Serial  Bus  (USB)  ports  cleverly 
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disguised  as  game  controller  ports  [4]  .  The  resemblance  of 
the  Xbox  to  a  common  PC.  On  the  left  is  the  hard  disk  drive 
and  on  the  right  is  the  DVD  drive.  It  is  thought  that 
Microsoft  chose  common  off-the-shelf  components  to  reduce 
cost,  development  time,  and  time-to-market.  Because  of  the 
use  of  such  common  components,  the  aforementioned  groups 
were  able  to  relatively  quickly  exploit  the  system  since  the 
groups  were  quite  familiar  with  how  PCs  and  their  peripheral 
devices  operated.  Andrew  Huang,  at  that  time  a  doctoral 
student  at  MIT,  is  credited  with  extracting  the  Xbox  basic 
input/output  system  (BIOS)  and  publishing  it  on  his  website. 
Eventually  he  was  able  to  intercept  the  RC4  encryption  key 
used  to  encrypt  the  bootloader  and  BIOS  by  monitoring 
traffic  on  the  HyperTransport  bus.  The  bootloader  and  BIOS 
were  then  modified  by  various  groups  to  allow  the  Xbox  to 
boot  executables  without  the  correct  RSA  signature  or  boot 
from  an  unapproved  media  (e.g.,  boot  from  the  Xbox  hard 
drive  vice  the  DVD  drive) .  The  altered  BIOS  and  bootloader 
prompted  the  widespread  piracy  of  Xbox  games.  Additionally, 
the  leaking  of  Microsoft's  official  Software  Development  Kit 
(SDK)  allowed  the  development  of  various  "homebrew" 
applications  and  the  porting  of  an  assortment  of 
applications.  It  is  possible  to  install  the  Linux  operating 
system  (OS)  on  the  Xbox  hard  drive  and  use  the  USB 
controller  ports  to  add  peripherals  such  as  a  keyboard  and 
mouse  [ 5 ] . 
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Figure  2.  Photograph  used  to  identify  Xbox  360  DVD  drives. 

The  successor  to  the  Xbox,  the  Xbox  360,  was  released 
in  November  of  2005.  Microsoft  hardened  the  internal  OS  of 
the  newer  system,  but  still  employed  common,  commercially 
available,  DVD  readers  in  its  product.  Two  of  the  many 
types  of  DVD  drives  utilized  are  illustrated  in  Figure  2. 
Eventually,  most  Xbox  360  DVD  drives'  firmware  were  reverse 
engineered  and  altered  to  report  all  media  inserted  into  the 
drives  as  authenticated.  Similar  reverse  engineering 
efforts  have  allowed  the  execution  of  unauthenticated  code 
on  products  such  as  Sony's  Play  Station  Portable,  Apple's 
Iphone,  and  various  GPS  receivers  running  the  Windows  CE  OS. 
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The  implications  of  such  actions  are  clear.  Unfunded 
groups  with  limited  resources  are  able  to  remove  security 
features  of  commercial  products  designed  to  deter  such 
actions.  A  well-funded  adversary,  such  as  state-sponsored 
information  warriors  or  non-state  actors  such  as  members  of 
organized  crime  syndicates  or  terrorist  organizations,  may 
be  able  to  exploit  DoD's  reliance  on  COTS  in  much  the  same 
way  or  perhaps  by  interfering  with  the  design,  development, 
and  implementation  of  COTS  components.  DoD  must  examine  the 
issues  surrounding  its  dependence  on  COTS  and  if  appropriate 
implement  more  stringent  acquisition  policies. 

It  is  not  enough  to  vet  just  the  components  of  systems. 
It  is  also  necessary  to  scrutinize  the  developers  or 
suppliers  of  the  components.  The  behavior  of  a  system 
containing  two  or  more  components  must  be  understood  too. 
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II .  BACKGROUND 


A.  INFORMATION  ASSURANCE  REQUIREMENTS  FOR  COMMERICIAL  OFF 

THE  SHELF  TECHNOLOGY 

Information  Assurance  (lA)  is  defined  as:  "Measures 
that  protect  and  defend  information  systems  by  ensuring 
their  availability,  integrity,  authentication, 
confidentiality,  and  non-repudiation..."  by  the  Committee  on 
National  Security  Systems  [6]  .  lA  provides  a  measure  of 
confidence  that  a  particular  software  or  hardware  system 
will  perform  as  designed  and  has  not  been  tampered  with  or 
compromised.  In  order  to  have  confidence  in  the  system,  we 
must  first  have  confidence  in  all  of  the  components  of  that 
system. 

The  Computer  Security  Act  of  1987  clarified  the 
definition  of  "national  security-related  information, "  and 
assigned  responsibility  of  all  federal  unclassified 
information  systems  (including  DoD  systems)  to  the  National 
Institute  of  Standards  and  Technology  (NIST) . 

However,  all  "national  security-related  information" 
systems  are  governed  by  the  National  Security  Agency  (NSA) . 
Therefore,  all  non-"national  security-related  information" 
COTS  IT  systems  must  meet  NIST's  lA  requirements. 

B.  lA  VULNERABILITIES  THROUGHOUT  THE  ENTIRE  LIFE  CYCLE 

Vulnerabilities  capable  of  negatively  affecting  lA  can 
be  introduced  anywhere  in  the  product  life  cycle.  Potential 
vulnerabilities  in  the  Systems  Development  Life  Cycle 
(SDLC) ,  vulnerabilities  during  implementation. 
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vulnerabilities  during  production  and  manufacturing,  and 
vulnerabilities  during  distribution  will  be  discussed  in 
this  chapter. 

Infiltrating  a  component  manufacturer's  development 
system  and  allowing  unsuspecting  users  to  install  components 
for  malactors  is  becoming  more  efficient  for  the  malactors 
than  attacking  each  installation  individually.  In  many 
cases,  infiltrating  the  development  cycle  presents  the 
weakest-link  in  the  component  life  cycle  [7] . 

1.  Systems  Development  Life  Cycle 

The  SDLC  refers  to  the  phases  of  development  of  a 
system.  There  are  many  well-known  SDLC  models,  the  most 
popular  of  which  are: 

•  Waterfall 

•  V-shaped 

•  Spiral 

•  Agile 

a .  Standard  SDLCs 

In  this  context,  the  term  "standard"  will  refer  to 
the  un-modified  or  academic  definition  of  each  of  the  SDLCs. 
Many  SDLCs  have  been  modified  to  fit  a  particular  use,  or  to 
fit  a  specific  timeline. 


8 


b. 


The  Waterfall  Model 


Figure  3.  Un-modi fied  "Waterfall"  model.  Work  proceeds  from 

the  top  phase  and  cascades  downward. 


As  illustrated  in  the  above  figure,  the  waterfall 
flows  from  one  phase  of  the  process  to  another.  Each  phase  is 
completed  sequentially,  and  one  phase  is  not  started  until  the 
previous  one  is  both  complete  and  verified.  The  phases 
include : 


•  Requirements:  The  systems  specifications  are 

established  to  include  constraints  and  goals, 
usually  by  analyzing  the  needs  of  the  users. 

•  System  design:  Divides  the  requirements  into 

either  hardware  or  software  as  appropriate  and 
establishes  an  overall  system  architecture. 
Determines  a  framework  by  which  requirements 
can  be  implemented.  Includes  user  interface, 
data  structures,  etc. 
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•  Implementation:  Each  component  of  the 

hardware  or  software  is  realized  and  tested 
to  ensure  it  meets  the  specification. 

•  Integration  or  installation:  Individual 

components  are  integrated  or  installed. 
Testing  is  performed  on  the  entire  system  to 
ensure  software  requirements  have  been  met. 

•  Operation  and  maintenance:  Usually  the 

longest  and  most  expensive  phase.  The  system 
is  put  into  use.  Maintenance  is  required  for 
undiscovered  deficiencies  [8]. 

The  "Waterfall"  model  is  easy  to  use  and  provides 
a  rigid  structure  to  the  developmental  process.  Milestones 
are  easy  to  discern  and  track.  However,  it  can  be  argued 
that  it  is  difficult  if  not  impossible  to  implement  this 
model  because  of  the  difficulty  in  completely  finishing  one 
phase  before  moving  on  to  the  next.  Additionally  if  the 
requirements  and  system  design  phases  were  not  correctly 
completed,  it  may  be  impossible  to  continue  to  implement  the 
system.  Following  the  Waterfall  model  makes  it  difficult  to 
modify  security  or  lA  requirements  in  later  phases.  Even 
with  these  possible  flaws,  this  model  (and  variations  of  it) 
is  often  used  for  acquisition  of  systems  in  which  quality  is 
more  important  than  cost  or  schedule. 
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c .  V-shaped  Model 


Figure  4.  V-Shaped  model. 

The  V-Shaped  model  is  a  variant  of  the  Waterfall 
model  that  puts  emphasis  on  verification  and  validation 
(V&V)  of  the  system.  The  model  ties  each  phase  of 
development  to  a  phase  of  testing 

The  V-Shaped  model  has  the  same  strengths  and 
weakness  as  with  the  Waterfall  but  is  more  suited  to  systems 
that  require  V&V  of  the  system  early  and  often  throughout 
development.  Additionally,  like  the  Waterfall  method,  it 
does  not  easily  allow  for  changing  requirements  or 
concurrent  events. 
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d.  Spiral  Development 


1.  Determine  objectives 


Review 

◄ - 


Require- 
f  ments  plan 


Cumulative  cost 

Progress 

► 


2.  Identify  and 
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Development 

plan 
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Release 


Concept  of  /  ReQuire-  j 
require-  ments  '  Draft 


Detailed  / 
design  / 


Verification 
&  Validation 


Verification 
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Code 

Integration 


Test 

Implementation 

I  - 

3.  Development  and  Test 


Figure  5 


Spiral  Model  (Boehm  1988) 


The  Spiral  model  was  proposed  by  Barry  Boehm  [9] . 
It  is  an  iterative  process  where  the  same  four  steps  are 
carried  out  for  each  phase  of  the  previously  discussed 
models.  For  example,  the  innermost  loop  might  represent 
requirements  gathering  and  the  next  loop  system  design,  etc. 
What  truly  distinguishes  the  Spiral  model  from  other  models 
is  that  the  model  calls  for  analyzing  risk  in  every  phase  of 
development . 
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The  Spiral  model  provides  an  indication  of 
insurmountable  risks  early  in  the  process  because  high-risk 
functions  are  often  developed  first.  The  model  promotes  the 
management  of  recognized  risks  prior  to  attempting 
traditional  phased  software  development.  The  Spiral  model 
is  appropriate  when  costs  and  risk  evaluation  are  important 
and  when  a  prototype  is  needed.  The  Spiral  model  may  be 
unsuitable  for  smaller  or  lower  risk  projects. 

e .  Compressed  SDLCs 

Pressure  to  be  first  to  market  and  retain  what  is 
known  as  mind  share  compresses  the  development 
cycle  so  much  that  software  engineering  methods 
are  often  thrown  out  the  window...of  ten  leaving 
rigorous  testing  to  the  users  [10]  . 

In  general,  SDLC  models  are  compressed  by 
overlapping  stages,  working  various  stages  of  the  model  in 
parallel,  or  both.  Compressing  the  development  cycle  can 
lead  to  decreased  time  for  testing.  Decreased  time  for 
testing  can  lead  to  an  increase  in  the  number  and  severity 
of  vulnerabilities  in  systems. 
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f.  Agile 


No. 

Principle 

Implication  for  Security 

1 

The  highest  priority  of  agile  developers  is  to  satisfy  the 
customer.  This  is  to  be  achieved  through  early  and 
continuous  delivery  of  valuable  software. 

Negative,  unless  customer  is  highly  security- 
aware.  There  is  a  particular  risk  that  security 
testing  will  be  inadequate  or  excluded  because 
of  “early  delivery  '  imperatives. 

2 

Agile  developers  welcome  changing  requirements,  even 
late  in  the  development  process.  Indeed,  agile 
processes  are  designed  to  leverage  change  to  the 
customer's  competitive  advantage. 

Negative,  unless  customer  is  careful  to  assess 
the  security  impact  of  all  new/changing 
requirements,  and  include  related  requirements 
for  new  risk  mitigations  when  necessary. 

3 

Agile  projects  produce  frequent  working  software 
deliveries.  Ideally,  there  will  be  a  new  delivery  every  few 
weeks  or,  at  most,  every  few  months.  Preference  is 
given  to  the  shortest  delivery  timescale  possible. 

Negative,  unless  customer  refuses  to  allow 
schedule  imperatives  to  take  precedence  over 
security. 

4 

The  project  will  be  built  around  the  commitment  and 
participation  of  motivated  individual  contributors. 

Neutral.  Could  be  Negative  when  the  individual 
contributors  are  either  unaware  of  or  resistant 
to  security  priorities. 

5 

Customers,  managers,  and  developers  must  collaborate 
daily,  throughout  the  development  project. 

Neutral.  Could  be  Positive  when  all  participants 
include  security  stakeholders  (e  g.,  risk 
managers)  and  have  security  as  a  key 
objective. 

6 

Agile  developers  must  have  the  development 
environment  and  support  they  need. 

Neutral.  Could  be  Positive  when  that 
environment  is  expressly  intended  to  enhance 
security. 

7 

Developers  will  be  trusted  by  both  management  and 
customers  to  get  the  job  done. 

Negative,  unless  developers  are  strongly 
committed  and  prepared  to  ensure  security  is 
incorporated  into  their  process  and  products. 

8 

The  most  efficient  and  effective  method  of  conveying 
information  to  and  within  a  development  team  is  through 
face-to-face  communication. 

Negative,  as  the  assurance  process  for 
software  is  predicated  on  documented 
evidence  that  can  be  independently  assessed 
by  experts  outside  of  the  software  project  team. 

9 

The  production  of  working  software  is  the  primary 
measure  of  success. 

Negative,  unless  “working  software"  is  defined 
to  mean  “software  that  always  functions 
correctly  and  securely.” 

10 

Agile  processes  promote  sustainable  development. 

Neutral 

11 

The  developers,  as  well  as  the  project's  sponsors  and 
the  intended  users  (either  of  whom  could  be  the 
“customer"),  should  be  able  to  maintain  a  constant  pace 
of  progress  indefinitely. 

Neutral 

12 

Agility  is  enhanced  by  continuous  attention  to  technical 
excellence  and  good  design. 

Positive,  especially  when  “technical  excellence 
and  good  design"  reflect  strong  expertise  in 
and  commitment  to  software  security. 

13 

Simplicity,  which  is  defined  as  the  art  of  maximizing  the 
amount  of  work  not  done,  is  essential  to  successful 
projects  and  good  software 

Positive,  if  simplicity  is  extended  to  the  design 
and  code  of  the  software  as  this  will  make  them 
easier  to  analyze  and  their  security  implications 
and  issues  easier  to  recognize. 

14 

The  best  architectures,  requirements,  and  designs 
emerge  from  self-organizing  teams.  At  regular  intervals, 
the  team  must  reflect  on  how  to  become  more  effective, 
then  tune  and  adjust  its  behavior  accordingly. 

Neutral 

Table  1.  Core  principles  of  the  Agile  Manifesto  (From  Department 
of  Homeland  Defense  in  Security  in  the  Software  Lifecycle) . 

The  Agile  model  operates  on  the  belief  that  it  is 
impossible  to  design  a  system  without  first  providing  a 
rudimentary  version  of  the  system  to  users  and  then 
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observing  the  results.  "It  may  be  only  after  a  system  is 
delivered  and  users  gain  experience  with  it  that  the  real 
requirements  become  clear"  [11].  Most  Agile-based  methods 
adhere  to  the  Agile  Manifesto  whose  principles  and 
applicability  to  security  are  listed  by  the  Department  of 
Homeland  Defense  in  Security  in  the  Software  Lifecycle  shown 
in  Table  1 . 


Method 

Abbreviation 

Author(s)/Affiliation 

Agile  Software  Process 

ASP 

Mikio  Aoyama/Nanzan  University 
and  Fujitsu  (Japan) 

extreme  Programming 

XP 

Kent  Beck,  Ward 
Cunningham.'Tektronix;  Ron 
Jeffries/Object  Mentor  and 
XProqramminq.com 

Crystal  family  of  methods 

None 

Alistair  Cockburn/IBM 

Adaptive  Software  Development 

ASD 

Jim  Highsmith,  Sam  Bayer/Cutter 
Consortium 

Scrum 

None 

Ken  Schwaber/Advanced 
Development  Methods;  Jeff 
Sutherland/PatientKeeper 

Feature-Driven  Development 

FDD 

Jeff  De  Luca/Nebulon 

Dynamic  System  Development 
Method 

DSDM 

DSDM  Consortium  (UK) 

Lean  Development 

LD 

*Bob  Charette/ITABHI  Corp. 

Whitewater  Interactive  System 
Development  with  Object  Models 

Wisdom 

Nuno  Jardim  Nunes/Universidade 
da  Madeira;  Joao  Falcao  e 
Cunha/Universidade  dao  Porto 

Table  2.  Major  Agile  Methods  (From  Department  of  Homeland 
Defense  in  Security  in  the  Software  Lifecycle) . 


Not  every  SDLC  shown  above  explicitly  takes  into 
account  security  in  its  procedures.  While  each  of  the  above 
SDLCs  can  produce  secure  components,  better  results  are 
achieved  when  security  is  considered  at  the  beginning  and 
throughout  the  process.  Retrofitting  security  onto  the 
product  or  component  (if  it  can  be  done  at  all)  after  it  has 
been  released,  does  not  lead  to  a  desired  security  state. 
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2 .  Development  and  Implementation  Strategies 


Development  strategies  are  ways  of  implementing  a 
product  or  service  and  include  incremental  development  and 
evolutionary  development. 

a.  Incremental  Development 

Incremental  development  involves  pre-planned 
segmented  development  of  the  product  or  components  in 
increments.  This  strategy  is  often  selected  to  accommodate 
funding  limitations,  handle  contractor  specialties,  simplify 
deployment  plans,  improve  development  sequence,  and  deal 
with  integration  issues  [12] . 

In  the  incremental  model,  customers  define  an 
outline  of  the  services  to  be  provided  by  the  system.  Each 
of  the  services  is  then  prioritized  and  a  number  of  delivery 
increments  is  defined  [13]  .  This  allows  for  the 
construction  of  a  partial  implementation  of  a  total  system. 
As  each  increment  is  added  to  the  total  system, 
functionality  is  increased.  Pieces  of  the  total  system  are 
provided  earlier  so  that  customers  can  immediately  benefit 
from  the  new  system.  This  model  requires  well-defined 
module  interfaces  (e.g.,  APIs  in  a  software  system)  since 
some  parts  of  the  system  will  be  delivered  much  earlier  than 
others.  The  incremental  approach  relies  on  a  divide-and- 
conquer  strategy  for  development. 

b .  Evol uti onary  Devel opmen t 

Evolutionary  Development  involves  successive 
improvements  of  products  or  components  based  on  experience 
with  prior  versions.  This  strategy  is  often  selected  to 
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accommodate  uncertain  requirements,  changing  problem 
environments,  and  challenging  technology  objectives  [14]. 

The  evolutionary  development  strategy  combines  the 
requirements,  design,  and  testing  phases  of  system 
development  to  quickly  produce  a  prototype  for  user  testing 
from  a  set  of  vague  user  needs.  The  prototype  is  then 
evaluated  by  the  end  users  and  feedback  is  submitted. 
Developers  take  the  feedback  and  improve  on  the  original 
prototype.  This  model  is  perceived  as  not  scaling  well  and 
is  thought  to  produce  un-organized,  un-maintainable  code 
that  is  difficult  to  reuse. 

Security  concerns  must  be  taken  into  account  when 
implementing  either  incremental  or  evolutionary 
developmental  strategies.  Special  consideration  should  be 
given  to  the  implementation  of  the  evolutionary  development 
strategy  because  it  is  likely  components  utilizing  this 
strategy  are  first-generation  and  lessons  learned  from 
previous  generation  component  installations  are  not 
available.  When  implementing  incremental  development 
strategies,  the  "lessons  learned"  and  any  other  information 
from  previous  use  or  installation  should  be  utilized  in 
order  to  avoid  making  the  same  mistake. 
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3. 


Production  and  Manufacturing  Vulnerabilities 


Global  Semiconductor  Sales 


Figure  6.  Global  Semiconductor  Sales  (data  from: 

Semiconductor  Industry  Association) . 

In  the  early  days  of  the  semiconductor  industry,  DoD 
and  NASA  represented  a  large  percentage  of  the  overall  sales 
of  all  semiconductors  and  therefore  could  easily  drive  the 
direction  of  product  development  and  dictate  manufacturing 
requirements.  In  today's  global  economy,  DoD  and  NASA  now 
represent  less  than  one  percent  of  the  worlds  semiconductor 
market  [15] .  "While  the  military  provided  the  original  test 
bed  for  many  computers  and  microelectronics,  defense  needs 
are  not  the  driver  for  the  newest  technologies  in  these 
fields  in  most  cases"  [16] . 

Market  forces  have  led  to  the  migration  of  the 
semiconductor  industry  from  industrialized  nations  such  as 
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the  United  States,  Japan,  and  Europe  to  countries  in  Asia 
where  the  cost  of  labor,  land,  and  material  are 
significantly  lower. 

This  migration  has  led  to  difficulties  of  trust  and  lA 
with  respect  to  these  semiconductor  components.  As  of  May 
2008,  49%  of  semiconductor  manufacturing  occurs  in  the  Asia 
Pacific  region  and  only  16%  occurs  within  North  and  South 
America . 

During  the  18th  century,  British  forests  became 
depleted  of  Baltic  fir,  prized  for  its  use  in  wooden  ships 
of  war.  In  order  to  fulfill  the  demand  for  quality  timber, 
the  British  turned  to  its  American  colonies  which  had  a 
nearly  infinite  supply  of  Live  oak  that  was  well  suited  for 
ship  construction  and  perhaps  better  suited  than  the  highly 
coveted  Baltic  fir.  The  American  colonies  began  exporting 
large  quantities  of  oak  across  the  Atlantic  for  use  by 
British  ship  builders.  Soon,  the  British  realized  it  would 
be  more  cost  efficient  to  send  ship  builders  across  the 
Atlantic  to  the  Americas  and  teach  the  soon  to  be  Americans 
how  to  build  ships.  Eventually,  the  colonists  became 
proficient  at  building  ships,  and  were  able  to  improve  upon 
the  British  methods.  This  outsourcing  eventually  allowed 
the  colonies  to  hoard  the  best  timber  for  themselves  in 
order  to  build  ships  such  as  the  USS  CONSITITUTION  that  were 
able  to  outrun  many  ships  of  the  line  at  the  time  and  proved 
invaluable  during  the  American  Revolution  [17] .  This 
anecdote  can  be  applied  to  today's  reliance  on  foreign 
manufacturing  of  COTS  components.  We  have  exported  COTS 
component  manufacturing  technology  overseas  in  an  effort  to 
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be  more  cost  efficient  without  taking  into  account  the 
possible  consequences  of  our  actions. 

4.  Distribution  Vulnerabilities 

The  networked  nature  of  the  modern  world  has  produced 
unique  distribution  vulnerabilities  with  respect  to  both 
hardware  and  software. 

a.  Distribution  Vulnerabilities  and  Software 

In  the  past,  software  was  distributed  either  by  a 
physical  medium  or  pre-installed  on  new  computer  systems. 
This  method  of  distribution  offered  some  assurance  since  it 
is  presumed  difficult  to  infiltrate  such  a  closed 
distribution  chain.  However,  with  the  popularity  of  the 
Internet,  online  distribution  is  more  prevalent  then  ever. 
Even  when  software  is  distributed  by  physical  means,  it  is 
almost  always  updated  via  the  Internet.  This  dependence  on 
a  publicly  accessible  network  to  update  software  has 
encouraged  malactors  to  infiltrate  the  software  distribution 
supply . 

On  August  22,  2008,  Red  Hat  released  a  statement 
indicating  that  an  intruder  into  their  network  was  able  to 
get  a  small  number  of  OpenSSH  packages  relating  to  its  Red 
Hat  Enterprise  Linux  versions  4  and  5  signed  by  Red  Hat's 
private  Public  Key  Infrastructure  (PKI)  key  [18]  . 

If  a  malactor  had  been  able  to  get  their  altered 
OpenSSH  signed  software  into  one  of  Red  Hat's  many  official 
mirrors  undetected,  they  would  have  easily  been  able  to 
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install  their  software  on  any  workstation  or  server  using 
these  mirrors  potentially  allowing  them  root  access  to 
thousands  of  machines. 

b.  Distribution  Vulnerabilities  and  Hardware 


Figure  7.  Counterfeit  and  genuine  Cisco  card  (from: 

http : / / WWW . andovercg . com/ services/ cisco-counterfeit- 

wic-ldsu-t 1 . shtml ) . 


On  January  4,  2008,  Michael  and  Robert  Edman  were 
charged  with  trafficking  in  counterfeit  Cisco  hardware  they 
had  purchased  from  an  individual  in  China.  The  counterfeit 
hardware  was  then  sold  through  middlemen,  and  shipped  to  the 
United  States  Marine  Corps,  Air  Force,  Federal  Aviation 
Administration,  Federal  Bureau  of  Investigation,  and  several 
defense  contractors,  universities  and  financial  institutions 
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[19] .  While  this  particular  incident  of  counterfeiting  has 
not  been  shown  to  be  anything  other  than  financially 
motivated,  the  implications  are  clear.  With  the  current 
global  supply  chain,  it  is  difficult  to  discern  exactly 
where  components  are  manufactured  and  under  what  conditions. 
Additionally,  intentionally  compromised  devices,  whether  for 
financial  gain  or  for  espionage,  constitute  a  threat  to 
national  security. 
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Ill .  J0SANG ' S  MODEL 


In  the  previous  chapter,  we  provided  examples  of  how 
vulnerabilities  throughout  the  entire  component  life  cycle 
were  exploited.  So,  how  does  one  know  what  components  to 
trust  in  mission-critical  yet  unclassified  systems?  One 
method  is  to  purchase  only  accredited  components  from 
trusted  manufacturers.  But,  how  do  we  assign  trust  to  these 
manufacturers?  Can  opinions  on  trust  be  calculated? 

In  his  thesis  "Trust  and  its  Ramifications  for  the  DoD 
Public  Key  Infrastructure  (PKI),"  Leonard  Gaines  analyzed 
five  different  trust  models  with  respect  to  their 
applicability  to  modeling  the  use  of  PKI  within  DoD.  After 
reviewing  each  of  the  models,  he  chose  to  apply  Audun 
Josang's  model  because  he  felt  it  was  the  most  comprehensive 
and  had  the  greatest  potential  to  be  practically  implemented 
[20].  We  feel  that  based  on  Gaines'  research,  Josang's 
model  will  provide  the  best  trust  model  for  calculating 
trust  with  respect  to  COTS  component  manufacturers. 

Audun  J0sang  presented  a  model  for  making  trust-based 
decisions  in  his  paper  "Trust-based  decision  making  for 
electronic  transactions"  in  1999,  in  which  he  focused  on 
using  his  technique  to  show  how  trust  in  remote  agents  can 
be  calculated  based  on  trust  recommendations  from  many 
different  sources  embedded  within  public  key  certificates 
used  in  public  key  cryptography. 

In  this  thesis,  we  demonstrate  the  applicability  of  his 
method  of  calculating  trust  to  manufacturers  of  COTS 
components.  We  assume  the  various  government  communities 
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will  provide  trust  recommendations  expressed  mathematically 
such  as  in  Josang's  method  explained  below  and  then  provide 
an  example. 

His  model  can  be  similarly  applied  to  other  areas  of 
the  product  life  cycle,  such  as  the  SDLC  or  applied  to 
software  and  hardware  distribution  chain. 

A.  J0SANG'S  MODEL  DEFINED 

J0sang  expresses  "opinions"  mathematically  as: 

b  +  d +  u  =  \,b,d,u (1.1) 


where  b,  d,  and  u  represent  belief,  disbelief,  and 
uncertainty,  respectively.  Uncertainty  is  used  when  there 
is  no  evidence  to  support  either  belief  or  disbelief.  An 
example  demonstrating  the  uncertainty  component  can  be  found 
in  Daniel  Ellsberg,  "Risk,  ambiguity,  and  the  Savage  axioms" 
reproduced  below: 

Let  us  suppose  that  you  confront  two  urns 
containing  red  and  black  balls,  from  one  of  which 
a  ball  will  be  drawn  at  random.  To  'bet  on  Red' 
will  mean  that  you  choose  to  draw  from  Urn  I;  and 
that  you  will  receive  a  prize  a  (say  $100)  if  you 
draw  a  red  ball  and  a  smaller  amount  b  (say  $0) 
if  you  draw  a  black.  You  have  the  following 
information:  Urn  I  contains  100  red  and  black 
balls,  but  in  ratio  entirely  unknown  to  you; 
there  may  be  from  0  to  100  red  balls.  In  Urn  II, 
you  confirm  that  there  are  exactly  50  red  and  50 
black  balls. 

The  probability  of  drawing  a  red  ball  from  Urn  II  is 
0.5,  since  there  is  an  equal  number  of  red  balls  and  black 
balls  in  the  urn.  However,  if  one  was  forced  to  make  a  bet 


on  the  outcome  of  drawing  a  red  ball  from  Urn  1,  where  one 

does  not  know  the  color  distribution  of  the  balls,  most 

people  will  still  agree  that  the  probability  of  drawing  a 
red  ball  is  0.5,  since  there  are  only  two  different  colors 
in  the  urn.  The  value  0.5  is  intuitively  selected  because 
there  are  only  two  possible  colors  6  =  {red , black)  and  that 

I  {ret/}  1=  I  ^  I  so  the  uncertain  probability  of  drawing  a  red 

would  have  been  0.5.  If  there  were  five  different  colors 

6  =  [red, black, blue, yellow, green)  then  |  {ret/}  |=  |  6*  |  and  the  uncertain 

probability  of  drawing  a  red  would  have  been  0.2.  This 

concept  of  calculating  the  uncertain  probability  given  only 
the  number  of  states  (number  of  distinct  colors  in  this 
case)  is  known  as  relative  atomicity,  denoted  by  a. 

This  example  illustrates  a  unique  phenomenon  where  in 
one  case  where  the  distribution  is  known,  and  in  the  other 
the  distribution  is  unknown,  yet  they  both  appear  to  have 
the  same  probability  of  being  selected,  0.5. 

In  Josang's  model,  w  =  {b,d,u,a)  is  an  ordered  quadruple 
whose  components  correspond  to  belief,  disbelief, 
uncertainty,  and  relative  atomicity,  respectively.  w  is 
defined  to  be  an  opinion.  An  opinion  has  an  ownership  which 

will  be  designated  by  a  subscript.  For  example,  denotes 

an  opinion  on  proposition  y,  held  by  agent  A. 

We  will  use  Josang  quadruples  in  Chapter  IV  to 
manipulate  opinions  of  COTS  component  manufacturers. 

The  probability  expectation  of  w,  denoted  by  E  (w)  is 
defined  by  Josang  to  be: 
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E{w)  =  b  +  au 


(1.2) 


The  probability  expectation  consists  of  belief, 

uncertainty,  and  relative  atomicity. 

B.  SUBJECTIVE  LOGIC 

J0sang  defines  an  algebra-based  method  for  manipulating 
opinions  on  binary  propositions  called  subjective  logic. 
Subjective  logic  contains  the  following  operators: 
conjunction,  disjunction,  negation,  recommendation,  and 
consensus.  The  first  three  operators  are  very  similar  to 
those  of  standard  Boolean  algebra.  However,  the 

recommendation  and  consensus  operators  are  what  set 
subjective  logic  apart  from  Boolean  algebra  and  standard 
logic . 


1. 

Conjunction  Operator 

Given  that  x  and  y  represent 

two  distinct  propositions 

denoted 

as  w^=iK,d„u^,a^)  and 

% 

=  iby,dy,Uy,ay  ) 

respectively. 

then  the 

belief  that  both  x  and 

y 

are  true  is 

represented  by 

=  iKy 

such  that: 

1. 

K.y  =Kby 

2. 

d,.y=d,  +  d^-djy 

3. 

4. 

bji  a  +u^a^b  +u^a^u  a 
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Therefore,  =w^/\Wy  . 


J0sang  defined 


and  ^  0 


this  as  a  conjunction. 


2.  Disjunction  Operator 


Given  that  x  and  y  represent  two  distinct  propositions 
denoted  as  and  =  (by,dy,Uy,ay)  respectively, 
then  the  belief  that  either  x  or  y  is  true  is  represented  by 

such  that: 


1 .  b  =b  +b  —b  b 

xvy  X  V  X  y 


2  d^dy 


3-  ^x.y=dxUy+u^dy+u^Uy 


^  ^  ^  ^  }  y  ^  y  y  x  ^  _y  x  x  y  y 


xvy 


u  +u  —bu  —ub  —uu 

X  y  X  y  X  y  x  y 


and  u^^y^O.  Therefore,  w^^y=w^AWy 
this  as  a  disjunction. 


J0sang  defined 


3 .  Negation  Operator 

A  negative  of  an  opinion  indicates  that  an  opinion  is 
false.  This  negation  is  similar  to  a  "NOT"  in  standard 
logic.  If  we  let  ={b^,d^,u^,a^)  be  an  opinion  about  a 

proposition  x,  then  has  the  following  properties: 


3 . 

4. 
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4. 


Recommendation  Operator 


J0sang  also  defined  a  recommendation  operator.  The 

recommendation  operator  allows  one  to  form  an  opinion  about 
something  based  on  someone  else's  opinion  about  it.  For 
example,  assume  there  are  two  agents,  A  and  B.  B  has  an 
opinion  about  a  proposition  x.  Josang's  model  allows  agent 
A  to  form  an  opinion  about  proposition  x  based  on  his 
knowledge  of  agent  B.  Let  A  and  B  be  two  agents  where 
Wg  =(bg,dg,u^,ag)  represents  A' s  opinion  about  B' s 

recommendations,  and  where  opinion 

about  X  shown  as  a  recommendation  to  A.  Let 

={b^^ ,a^^)  ,  then  has  the  following  properties: 


1.  bf=bX 

2.  df=bid: 

3  .  =(1^  -\-Ug 


4  . 


is  called  the  recommendation  between  Wg  and  , 
expressing  A's  opinion  about  x  as  a  result  of  the 
recommendation  from  B.  Josang  uses  the  symbol  ®  to  define 

AB  A  /0\  B 

Wx  =Wg  . 


It  can  be  proved  that  the  recommendation  operator  is 
associative  but  not  commutative.  This  implies  that  the 
order  in  which  opinions  are  combined  is  significant.  The 
recommendation  operator  assumes  that  with  a  chain  including 
more  than  one  opinion,  each  opinion  is  formed  independently 
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of  other  recommendations.  This  implies  that  the  same  entity 
should  not  appear  more  than  once  in  any  chain. 

We  will  use  Josang's  recommendation  operator  in  Chapter 
IV  to  show  how  opinions  of  COTS  component  manufacturers  can 
help  us  form  opinions  on  their  sub-contractors  based  on  our 
trust  in  the  component  manufacturer. 


5.  Consensus  Operator 


J0sang  defines  a  consensus  operator  as  one  that 
combines  opinions  on  the  same  proposition  in  a  fair  and 
equal  way.  For  example,  suppose  two  different  professors 
observed  the  work  ethic  of  a  particular  student.  Each 
professor  might  have  formed  a  different  opinion  about  the 
student  dependent  on  the  behavior  of  the  student  at  that 
particular  time.  The  Bayesian  approach  dictates  that  the 
consensus  operator  must  then  be  the  opinion  that  a  single 
professor  would  have  after  observing  the  student  during  both 
periods.  Josang  [21]  showed  the  following  definition 
corresponds  to  this  approach  and  is  based  on  Bayesian 
calculus . 


Let  =ib^ ,u^ ,a^)  and  )  be  the  opinions 

of  Agents  A  and  B  respectively  about  the  same  proposition  x. 


.A,B 


II 

is  the 

1. 

bt'^  =  {bX+bX)ik 

2. 

dr=(dX+dX)lk 

3. 

ut^-{uX)lk 

4. 

BA,  A  B  /  A 

a,b  _a,u^  +a^u^  -K 

X  X 
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Where  k  =  u^+u^-u^u^  and  where  =u^  and  =  ul  ^  \  . 
J0sang  calls  this  the  consensus  operator  between  and  irf 

and  uses  the  symbol  ©  to  represent  it  and  defined  it  as 
w‘^'^=w^@w^.  It  indicates  an  imaginary  agent  [A,  B]  ' s 
opinion  about  x,  as  if  it  represented  both. 

It  can  be  proved  that  the  consensus  operator  is  both 
commutative  and  associative.  This  implies  that  the  order  in 
which  the  opinions  are  combined  has  no  influence  on  the 
calculation.  As  with  the  recommendation  operator, 

independence  of  each  opinion  within  the  chain  is  assumed. 

We  will  use  Josang's  consensus  operator  in  Chapter  IV 
to  combine  multiple  independent  opinions  of  COTS  component 
manufacturers  into  one  opinion  in  an  equal  and  fair  manner. 
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IV.  ANALYSIS 


We  argue  J0sang's  model  can  be  used  to  form  an  overall 
opinion  about  manufacturers  of  COTS  components  based  upon 
multiple  entities  opinions  using  the  subjective  logic 
consensus  operator. 

Additionally,  one  could  use  Josang's  subject  logic 
recommendation  operator  to  form  an  opinion  on  a  separate 
entity's  opinion  about  something  or  someone.  For  example, 
assume  there  exist  two  agents  A  and  B  where  agent  A  has  an 
opinion  about  B' s  trustworthiness  and  B  has  an  opinion  on 
proposition  x.  Josang's  recommendation  model  allows  agent  A 
to  form  an  opinion  on  proposition  x.  This  could  be  useful 
for  forming  an  opinion  on  a  subcontractor  x  that  works  for 
agent  B. 

In  this  chapter,  we  provide  examples  implementing  both 
Josang's  consensus  and  recommendation  operators  based  on 
opinions  provided  by  trusted  third  parties. 

A.  EXAMPLE  OF  J0SANG'S  CONSENSUS  OPERATOR 

If  multiple  government  agencies  formed  independent 
opinions  of  a  fictitious  integrated  circuit  manufacturer, 
the  consensus  operator  will  allow  for  the  formation  of  one 
opinion,  taking  all  into  account  equally  and  fairly.  This 
should  reduce  uncertainty. 

In  this  example,  we  will  examine  a  fictitious 
integrated  circuit  manufacture  called  Super  Good  ICs  Inc, 
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using  fabricated  information  provided  by  three  intelligence 
communities  that  we  will  refer  to  as  Intelligence  Agencies 
A,  B,  and  C. 

This  scenario  will  operate  on  three  important 
assumptions.  The  first  assumption  is  that  each  of  the  three 
intelligence  agencies  acquired  the  information  that  they 
used  to  form  their  opinion  independently  of  the  others. 

The  second  assumption  is  that  each  of  the  intelligence 
agencies  has  enough  knowledge  to  make  an  informed  opinion 
about  Super  Good  ICs  Inc. 

The  last  assumption  is  that  each  of  the  intelligence 
agencies  can  be  trusted  to  provide  an  honest  opinion  of 
Super  Good  ICs  Inc,  e.g.,  they  have  not  been  infiltrated  or 
influenced  in  some  way  by  another  entity. 

Recall  that  the  consensus  operator  in  subjective  logic 
(represented  by  ©  )  allows  for  the  combining  of  multiple 
opinions  about  the  same  proposition  into  one  single  opinion 
taking  all  into  account  equally  and  fairly. 

Let  ~  {bgQ,d and  —{b^Q,d^Q,UgQ,a^Q)  be  the 
opinions  of  agency  A  and  B  respectively  about  whether  Super 
Good  ICs  Inc  is  not  producing  chips  that  have  extra, 
unauthorized  functionality.  For  this  example,  let 
>V5(j  =  (.85,.01,.14,.50)  and  =  (.80,.05,.15,.50)  represent  belief, 
disbelief,  uncertainty,  and  atomicity.  Atomicity  is  .5 
because  there  exist  only  two  possibilities.  Super  Good  ICs 
is  providing  altered  chips  or  it  is  not. 

is  calculated  using  the  equations  shown 
Chapter  III  as  follows: 
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1 .  =  {bscUsG  +  blGuta  )  /  ^  =  (.85  M  5  +  .80  * .  14)  /  (.  14  + .  1 5  - .  14  * .  1 5)  =  .89 

2.  =(J4M^e+JfgM^e)/^  =  (-01*-15  +  .15M4)/(.14  +  .15-.14M5)  =  .08 

3.  =(M4M^g)/^  =  (.14M5)/(.14  +  .15-.14M5)  =  .08 

4  . 

^A,B  _  VtG+^SG^SG-(^SG+^SG)VsG  _  -5  * .  14  +  .5  * .  1 5  -  (.5  +  .5)  * .  14  * .  1 5)  _  ^ 
Usg+Usg-^Vsg  .14  +  . 15 -2*. 14*. 15 

Where  k  =  u^+u^-u^u^  and  where  =u^  ^0  and  =u^  ^  \  . 
=  (.89,  .08,. 08,. 5)  is  the  consensus  of  and  i+f  is 

represented  by  . 

However,  if  agency  C  has  evidence  that  Super  Good  ICs 
Inc  is  using  substandard  materials  likely  to  cause  the  chips 
to  fail  in  an  unacceptable  period  of  time  and  has  formed  the 
following  opinion  =  (.01,.95,.04,.50)  then  ®w'^g  becomes: 

1. 

=(Z>//m^^+Z>^^m4^)/^  =  (.89*.04  +  .01*.08)/(.08  +  .04-.08*.04)  =  .31 

2. 

=  {dsiu%  +  dsoutc)!  b  =  (.89  *  .04  +  .04  *  .08)  /  (.08  +  .04  -  .08  *  .04)  =  .33 
3  .  =  {utiu% ) / ^  =  (.08 * .04) /  (.08  +  .04 - .08 * .04)  =  .03 

4. 


(A,B),c  _  +aiiu%-{asG  _  ■5*.08  +  .5*.04-(.5  +  .5).08*.04 


^SG 

OL7  ^  OKJ  A  OUT 

UsQ  ^^SG  ^SG 

_ 

.08  +  .04-2*.08*.04 

.5 

Where 

7  A,B  ,  C  A,B  C 

k  —  Ux  ~^x  ^x 

and 

where  =u^  ^0 

and 

A,B 

u 

X 

=  u^  ^  1  • 

^(+nc^(_31,_33,_03,_5) 

is 

the  consensus  of 

and 

is  represented  by 
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B.  EXAMPLE  OF  J0SANG'S  RECOMMENDATION  OPERATOR 

The  recommendation  operator  can  be  used  to  form  an 
opinion  based  on  someone  else's  recommendation.  For 

example,  if  Agency  A  had  an  opinion  on  COTS  manufacturer  B, 
and  COTS  manufacturer  B  had  an  opinion  on  subcontractor  s, 
then  we  can  calculate  A's  opinion  on  s  using  Josang's  model. 

Let  Wg  =(bg  ,d^ ,Ug,a^)  represents  A' s  opinion  about  B' s 
recommendations  and  let  ={b^  ,d^  ,u^  ,a^)  represent  B' s 

opinion  about  s. 

Given  that  =  (.90, .05,. 05, .5)  and  =  (.95,.02,.03,.5)  ,  A's 
opinion  about  s,  represented  by  w^=Wg®w^  is  calculated  as 
follows : 

1.  bf  =bX  =  .90*.95  =  M 

2.  df  =bid^  =  .99^m  =  m 

3.  uf  =di+Ug+bgU^^  =.95 +  .95  +  . 99*  m  =  .U 

A  AB  B  r 

4  .  =a^  =.5 

is  Agency  A's  opinion  on  COTS  manufacturer  B' s 
subcontractor  s,  formed  based  on  B' s  opinion  and  A's  "trust" 
in  B' s  opinion.  wf  is  calculated  to  be  wf  =  (.S6,.92,.\3,.5)  and 
is  represented  by  wf  =Wg®w^  . 

C.  USING  THE  RESULTS  OF  THE  CALCULATED  TRUST  OPINION 

The  calculated  trust  opinion  represents  the  combination 
of  others  opinions  about  certain  propositions.  How  to  act 
on  the  calculated  opinion  is  subjective.  The  final  decision 
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on  how  to  act  on  the  calculated  trust  opinion  will  depend  on 
many  factors  such  as  the  persons  or  agencies  aversion  to 
risk,  the  value  of  the  proposition  being  considered,  and  the 
consequences  of  making  a  bad  decision. 

In  an  automated  system,  the  decision  to  accept  or 
reject  a  proposition  could  be  based  on  pre-defined  threshold 
values  established  by  the  organizations  policy  makers 

D.  WEAKNESSES  WITH  J0SANG'S  MODEL 

Implementing  Josang's  model  will  require  opinions 
formed  using  consistent  methods  able  to  contend  with  a 
variety  of  situations  on  a  limited  number  of  propositions. 
Additionally,  it  will  be  difficult  to  verify  that  the 
opinions  formed  by  each  intelligence  agency  were  formed  from 
independent  sources. 

1 .  Forming  Good  Opinions 

Analysts  expressing  the  opinions  of  their  respective 
organizations  (such  as  from  U.S.  government  agencies,  non¬ 
government  organizations,  various  private  sector  companies, 
and  select  foreign  partners)  will  be  required  to  form 
opinions  based  upon  their  particular  organizations  knowledge 
of  an  outside  organization  with  respect  to  a  certain 
proposition.  One  possible  way  of  assigning  belief  values  is 
as  follows: 

•  Very  strong  belief  in  the  proposition  (belief 
value  from  1.00  to  .90) 

•  Strong  belief  in  the  proposition  (belief  value 
from  .89  to  .70) 

•  Belief  in  the  proposition  (belief  value  from  .69 
to  .50) 


35 


•  Dis-belief  in  the  proposition  (belief  value  from 
.49  to  .40) 

•  Strong  dis-belief  in  the  proposition  (belief  value 
from  .39  to  .10) 

•  Very  strong  dis-belief  in  the  proposition  (belief 
value  from  .09  to  .0) 
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V.  CROSS  DOMAIN  INFORMATION  SHARING 


Chapter  IV  illustrated  a  formal  model  for  calculating 
measures  of  trust  using  opinions  of  parties  interested  in 
the  COTS  components.  However,  where  would  one  obtain  such 
opinions  and  how  would  they  be  stored?  In  order  to  implement 
Josang's  trust  model  to  COTS  component  manufacturers,  we 
would  ideally  generate  opinions  about  a  particular 
manufacturer  from  large  repositories  of  information  from  all 
available  sources,  including  U.S.  government  agencies,  non¬ 
government  organizations  (NGOs) ,  various  private  sector 
companies,  and  select  foreign  partners. 

This  system  would  need  to: 

•  Share  information  across  many  domains  spanning 
organizational  boundaries 

•  Accept  input  from  multiple  security  levels 

•  Output  information  to  multiple  security  levels 
while  protecting  the  sources  and  methods  used  to 
obtain  the  information 

•  Utilize  mixed  model  access  control  (i.e.,  the 
Bell-Padula  model  on  its  own  is  insufficient) 

•  Enforce  domain-specific  declassification  polices 
and  rules 

•  Be  trustworthy  as  defined  in  Chapter  I 

Currently,  there  is  no  formal,  efficient,  and  practical 
method  used  to  share  information  spanning  multiple  domains 
(e.g.,  DoD,  NGOs,  industry,  etc)  and  multiple 
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classifications.  Implementation  of  a  cross  domain 
information  sharing  model  will  allow  cooperation  among 
disparate  organizations  that  might  not  otherwise  know  other 
organizations  are  working  on  the  same  problem. 


Figure  8.  Proposed  Radiant  Alloy  Architecture  for  High 

Assurance  Systems  available  from 
http : / /www. nps . edu/Research/mdsr/Docs/Vol28Mar08 .pdf . 


A  proposed  system  that  meets  some  of  the  requirements 
is  illustrated  in  Figure  8.  Radiant  Alloy  is  expected  to 
provide  access  using  both  MLS  and  Role  Based  Access  Control 
(RBAC)  models.  In  the  proposed  model,  MLS  will  be  used  to 
divide  the  various  classification  domains  and  RBAC  will  be 
used  to  provide  fine  grain  access  control. 

The  combining  of  these  two  methods  for  access  control 
might  result  in  unexpected  weaknesses  in  the  model;  Radiant 
Alloy  is  already  undergoing  preliminary  C&A.  Additionally, 
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convincing  the  above  organizations  to  share  information  with 
organizations  that  they  have  not  individually  vetted  might 
prove  difficult. 

Radiant  Alloy  will  broker  information  in  an  enterprise, 
multilevel  secure  (MLS)  system  using  mixed  model  access 
control.  This  system  would  be  tiered  in  such  a  way  as  to 
prohibit  the  transfer  of  classified  information  to 
organizations  without  the  required  clearances  or  need  to 
know.  Figure  8  illustrates  the  concept  of  an  Information 
Broker  (IB),  an  information  management  controller  in  the 
information  sharing  system  which  acts  as  an  intermediary 
between  the  requestor  of  the  information  and  the  data 
repositories  [22]  .  The  IB  should  provide  the  requested  data 
without  allowing  the  user  the  ability  to  know  or  infer  the 
original  source  of  the  data  (i.e.,  the  "safety  property" 
which  guards  against  information  leakage.  One  method  of 
doing  this  is  to  encapsulate  the  data  under  the  IB's  name, 
maintaining  the  confidentiality  of  the  requestor  and 
providing  repository.  The  IB  requests  data  through  the 
Trusted  Database  Connector  (TDC)  to  fulfill  user  requests. 
The  IB  is  intended  to  be  a  highly  reliable  component  of  the 
information  sharing  system,  able  to  access  various 
classifications. 

For  example,  if  a  U.S.  intelligence  agency  has 
classified  information  that  indicates  a  particular  COTS 
component  manufacturer  has  added  a  method  of  bypassing 
normal  authentication  methods  to  their  products,  it  could 
indicate  so  in  their  opinion  in  the  shared  information 
database.  However,  if  the  information  was  retrieved  by  an 
agency  without  the  proper  clearance  or  need  to  know,  the 
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opinion  can  be  "downgraded"  by  decreasing  either  the  belief 
or  disbelief  component  of  Josang's  quadruple  while 
increasing  the  uncertainty  component.  A  similar  method  is 
used  with  respect  to  the  Global  Positioning  System  (GPS) 
called  selective  availability  (SA)  .  SA  introduces 
intentional,  slowly  changing  random  errors  of  up  to  a 
hundred  meters  in  the  publicly  available  navigation  signals 
to  prevent  mal  actors  from  using  GPS  based  weapons.  An 
encoded  GPS  signal,  the  Precise  Positioning  Service  (PPS) , 
which  does  not  contain  the  SA  errors,  is  primarily  used  by 
the  DoD  [23]  . 

Cover  stories  can  be  created  to  obfuscate  the  reasoning 
behind  the  opinion  to  un-cleared  organizations  such  as 
justifying  poor  opinions  based  on  poor  reliability  and/or 
manufacturing  defects,  poor  treatment  of  factory  workers, 
etc.,  when  in  fact  it  is  due  to  purposeful  modifications  to 
components . 
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VI.  CONCLUSIONS  AND  FUTURE  WORK 


The  reliance  on  COTS  components  by  DoD  may  be  exploited 
by  well-funded  adversaries  either  by  discovering  existing 
un-intentional  defects  or  weaknesses  in  the  components  used 
(since  they  have  access  to  the  same  components)  or  by 
introducing  vulnerabilities  at  some  point  during  the  product 
lifecycle . 

Josang's  model  can  be  used  to  calculate  trust  in  COTS 
manufacturers  and  their  COTS  components  by  providing  a 
systematic  and  formal  way  to  combine  the  opinions  of 
multiple  entities  about  the  manufacturers  and  their 
components.  Additionally,  it  provides  the  unique  ability  of 
calculating  the  trust  in  a  different  entity's  opinion  based 
on  how  much  "trust"  is  placed  in  the  entity  submitting  the 
opinion . 

To  utilize  the  proposed  trust  model,  DoD  will  need  to 
implement  a  cross  domain  information  sharing  scheme  such  as 
outlined  in  Chapter  V.  Populating  this  system  will  require 
various  U.S.  government  agencies,  NGOs,  various  private 
sector  companies,  and  select  foreign  partners  to  submit 
opinions  in  a  consistent  and  standard  way. 

We  recommend  that  DoD  only  utilize  accredited 
components  manufactured  by  trusted  factories  tested  within 
the  components  common  and  not  so  common  applications  in 
mission-critical  and  performance-intensive  activities. 
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A. 


FUTURE  WORK 


1 .  Automation 

The  desired  end  state  of  this  proposed  information 
sharing  and  trust  model  is  for  the  end  user  to  be  able  to 
quickly  and  easily  access  trust  information  about  component 
manufacturers  suitable  for  his  or  her  role.  This  would  be 
most  easily  accomplished  through  an  automated  system. 

a.  Populating  the  Model 

This  proposed  method  for  calculating  trust  could 
be  more  widely  applied  if  the  information  repository  the 
model  uses  to  calculate  opinions  is  populated  by  some 
automated  means.  Such  automation  could  pull  information 
about  individual  components  from  various  statistics 
including:  reliability  statistics,  failure  rates, 
survivability  data,  expected  component  life,  method  of 
failure  (catastrophic  vs  graceful  degradation),  etc.  An 
appropriate  opinion  can  then  be  calculated  using  the  amount 
of  information  available  as  a  guide  for  the  belief, 
disbelief,  and  uncertainty  values. 

b.  Generating  Opinions  from  the  Model 

With  a  populated  repository  of  opinions,  the 
automation  of  generating  the  appropriate  opinions  should  be 
straight  forward.  However,  determining  appropriate 
threshold  values  on  whether  to  engage  in  a  transaction  might 
prove  challenging  since  different  users  have  different 
tolerances  with  respect  to  risk. 


42 


2. 


Improving  upon  J0sang ' s  Model 


Is  J0sang's  too  generalized  to  be  successfully  utilized 
in  such  a  manner?  Josang's  subjective  logic  trust  model 
allows  the  calculation  of  trust  with  uncertainty  and 
incomplete  information. 

Josang's  model  could  provide  too  much  latitude  when 
forming  opinions.  He  does  not  provide  guidelines  on  how  to 
formulate  opinions  or  how  to  assign  values  to  them. 

Defining  discrete  values  for  opinions  will  be  necessary 
in  order  to  resolve  ambiguity  with  the  implementation  of  his 
model.  Currently,  many  Department  of  the  Navy  (DoN) 
projects  are  tracked  using  the  colors  red,  yellow,  or  green 
to  indicate  behind  schedule,  at  risk  for  falling  behind 
schedule,  and  on/ahead  of  schedule  respectively.  It  appears 
obvious  that  further  granularity  would  be  needed  to 
implement  this  model,  but  how  much  more?  Are  ten  distinct 
divisions  (e.g.,  scale  of  one  to  ten)  enough  to  provide  the 
desired  precision?  Or  are  more  divisions  desirable? 

3 .  Implementing  the  Model 

How  much  would  it  cost  to  implement  such  an  information 
sharing  scheme?  Who  would  pay  for  such  a  system?  Would  it 
be  paid  for  by  one  organization,  or  would  the  costs  be 
shared  amongst  all  of  its  users? 

What  policies  and/or  regulations  need  to  be  altered  in 
order  to  share  such  information  amongst  these  organizations? 
Does  the  proposed  Radiant  Alloy  system  meet  the  requirements 
set  forth  in  Chapter  V?  Do  any  other  current  or  proposed 
systems  meet  our  system  requirements? 
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Once  such  a  system  is  established,  working  groups  with 
representation  from  all  concerned  organizations  would  need 
to  be  established  to  determine  how  their  respective 
information  would  be  migrated  into  the  new  information 
sharing  system. 
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